ATTORNEY DOCKET NO. 
062891.0505 



13 



PATENT APPLICATION 
09/745,909 



REMARKS 

This Application has been carefully reviewed in light of the Office Action mailed 
January 25, 2005. Claims 1-2, 4-17, 19-32, and 34-37 are pending in the Application. 
Claims 3, 18, and 33 have been withdrawn from consideration. The Examiner rejected 
Claims 1-2, 4-17, 19-32, and 34-47. Applicants note with appreciation Examiner's approval 
of the amended specification. Applicants have amended Claims 1, 16, 31, and 46. 
Applicants submit that no new matter has been added with these amendments. As described 
below. Applicants believe all claims to be allowable over the cited references. Therefore, 
Applicants respectfully request reconsideration and full allowance of all pending claims. 

Section 103 Rejections 

The Examiner rejects Claims 1-2, 4-5, 13-14, 16-17, 19-20, 28-29, 31-32, 34-35, 43- 
44, and 46 under 35 U.S.C. § 103(a) as being unpatentable over U.S. Patent No. 6,351,467 
Bl issued to Dillon {"Dillon'') in view of U.S. Patent No. 6,791,981 Bl issued to Novaes 
("Novaes''). For the following reasons. Applicants respectfully request reconsideration of 
Claims 1-2, 4-5, 13-14, 16-17, 19-20, 28-29, 31-32, 34-35, 43-44, and 46. 

Independent Claim 1, as amended, recites: 

A method for authenticated access to multicast traffic, comprising: 
receiving an Internet group management protocol request at an 
access network router, the request identifying a user requesting to join an 
IP multicast channel, the IP multicast channel selected firom a bundle of IP 
multicast channels offered as a multicast package on a subscription basis; 

authenticating access privileges of the user to the multicast 
channel; and 

disallowing the request in response to at least an unsuccessful 
authentication. 

Applicants respectfully submit that the proposed Dillon-Novaes combination does not 
disclose, teach, or suggest each and every limitation recited in Applicants' Claim 1. For 
example. Applicants respectfully submit that neither Dillon nor Novaes disclose, teach, or 
suggest "receiving an Internet group management protocol request at an access network 
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router, the request identifying a user requesting to join an IP multicast channel," as recited in 
amended Claim L With respect to the recited "Internet group management protocol request," 
the Examiner acknowledges that Dillon does not disclose the feature. (Office Action, 
page 3). Rather, the Examiner relies upon Novaes for disclosure of the "Intemet group 
management protocol request." However, the portion of Novaes relied upon by the Examiner 
merely discloses that a "beacon message [is transmitted] over subnetworks 310, 320, and 330 
using the multicast protocol." (Column 8, lines 39-40, [sic]). Although Dillon discloses that 
the "mechanism used to control the distribution of the multicast messages is based on the 
Intemet Group Management Protocol (IGMP) as specified in RFC 1112" (Column 8, lines 
40-43), there is no disclosure in Novaes that an IGMP request is received that "identif[ies] a 
user requesting to join an IP multicast channel," as recited in Claim 1. To the contrary, the 
"beacon message" is disclosed as comprising "a short status datagram, which is called 
heartbeat message or beacon status message." (Column 8, lines 26-28). Thus, the beacon 
message of Novaes is merely a status message. There is no disclosure in Novaes of 
"receiving an Intemet group management protocol request at an access network router, the 
request identifying a user requesting to join an IP multicast channel," as recited in amended 
Claim 1. 

As a further example of the deficiencies of the Dillon-Novaes combination. 
Applicants respectfully submit that the proposed combination of references also does not 
disclose, teach, or suggest that "the IP multicast channel selected from a bundle of IP 
multicast channels offered as a multicast package on a subscription basis," as recited in 
amended Claim 1. As discussed in the previous Response to Office Action submitted on 
August 25, 2004, Dillon merely discloses that a user may "subscribe to WebCast Channels of 
interest," the content of which is "specified by a WebCast channel definition . . . [that] is 
predetermined." With regard to the offered WebCast Channels, Dillon further discloses that 
"a channel is a set of URL data items which a user may be interested in repeatedly 
accessing." (Column 7, lines 32-35). More specifically, Dillon discloses that "[a] channel 
ordinarily is a subset of a web site's content (i.e. a set of web pages) to be periodically 
extracted from the web site by a web crawler and delivered to subscribing users by 
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conditional access protected multicast file transfer." (Column 7, lines 35-39). "Thus, a 
channel's content consists of a collection of URL data items, typically all from a single web 
site." (Column 7, lines 39-40). To receive the multicast content offered on each WebCast 
channel, Dillon discloses that "a content viewer 58 in the receiver 26 provides the user with 
the promotional material (i.e. through the Electronic Program Guide (EPG)) that helps the 
user to determine which channels to subscribe to." (Column 16, lines 53-57), "[T]he content 
viewer 58 . . . processes a user's requests to subscribe to or unsubscribe a channel." (Column 
20, lines 46-49). Thus, the user subscribes to the WebCast channels on a channel by channel 
basis. The WebCast channels are not bundled and "offered as a multicast package on a 
subscription basis," as recited in amended Claim 1. 

The deficiencies of Dillon are not cured by the combination of Dillon with Novaes, 
To the contrary, Novaes merely discloses "[a] method for building a hierarchical multicast 
tree which is centered around a specific node in an Intemet Protocol (IP) communications 
network." (Abstract). The method of Novaes includes "[rjeceiving a configuration tile 
containing a list of all the network addresses of the nodes in a network," "receiving a number 
of permissible connections each subnetwork leader node in the network is permitted with 
other subnetwork leader nodes," and "establishing a multicast connection between each 
subnetwork leader node as identified in the configuration file." (Abstract). Accordingly, 
there is no disclosure in Novaes of an "IP multicast channel selected from a bundle of IP 
multicast channels offered as a multicast package on a subscription basis," as recited in 
Applicants' Claim 1. 

For at least these reasons Applicants respectfially request reconsideration and 
allowance of Claim 1, together with Claims 2, 4-5, and 13-14, which depend fi-om 
independent Claim 1 . 

Independent Claims 16, 31, and 46 recite certain features and operations that are 
substantially similar to the features of Claim 1. For example, Claim 16 recites "means for 
receiving an Intemet group management protocol request at an access network router, the 
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request identifying a user requesting to join an IP multicast channel, the IP multicast channel 
selected from a bundle of IP multicast channels offered as a multicast package on a 
subscription basis." As another example, Claim 31 recites "logic operable to receive an 
Internet group management protocol request for a user to join an IP multicast charmel 
selected from a bundle of IP multicast channels offered as a multicast package on a 
subscription basis." Claim 46 recites "authenticating access privileges of a user to the EP 
multicast channel upon receiving an Internet group management protocol request at an access 
network router, the request identifying a user requesting to join an IP multicast channel to 
receive the premium video content, the IP multicast channel selected from a bundle of EP 
multicast channels offered as a multicast package on a subscription basis." Accordingly, for 
reasons similar to those discussed above with regard to Claim 1, Applicants respectfully 
submit that the proposed Dillon-Novaes combination does not disclose, teach, or suggest each 
and every element recited in Applicants' Claims 16, 31, and 46, Claims 17 and 19-20, and 
28-29 depend directly or indirectly upon Claim 16. Claims 32, 34-35, and 43-44 depend 
directly or indirectly upon Claim 31. Thus, for the same reasons that independent Claims 16, 
and 3 1 are allowable, these dependent claims are also allowable. 

For at least these reasons. Applicants respectfully request reconsideration and 
allowance of Claims 1-2, 4-5, 13-14, 16-17, 19-20, 28-29, 31-32, 34-35, 43-44, and 46. 

The Examiner rejects Claims 6-12, 15, 21-27, 30, 36-42, and 45 under 35 U.S.C, 
§ 103(a) as being unpatentable over various combinations of Dillon, Novaes, U.S. Patent No. 
6,219,790 Bl issued to Lloyd et al. {"Lloyd"'), U.S. Patent No. 6,446,571 Bl issued to 
Dynarski et al. {''Dynarske'), U.S. Patent No. 6,718,387 Bl issued to Gupta et al. ("Gupta''), 
and U.S. Patent No. 6,026,441 issued to Ronen ("Ronen"), 

Claims 6-12 and 15 depend from independent Claim 1 and incorporate the features of 
Claim 1, which Applicants have shown above to be allowable. Claims 21-27 and 30 depend 
from independent Claim 16 and incorporate the features of Claim 16, which Applicants have 
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shown above to be allowable. Claims 36-42 and 45 depend from independent Claim 31 and 
incorporate the features of Claim 31, which Applicants have shown above to be allowable. 
Applicants respectfully submit that dependent Claims 6-12, 15, 21-27, 30, 36-42, and 45 are 
allowable at least because of their dependency. 

Additionally, Applicants respectfully submit that the proposed combination(s) of 
references do not disclose, teach, or suggest each and every limitation recited in Applicants' 
Claims 6-12, 15, 21-27, 30, 36-42, and 45. As examples. Applicants respectfully submit that 
the proposed combinations of references does not disclose, teach, or suggest the following 
features recited in Applicants' claims: 

• "determining whether the user is logged in to a service provider providing the 
multicast channel" and "unsuccessfully authenticating access privileges of the 
user to the multicast channel in response to at least the user not logged in to 
the service provider," as recited in Claims 10 and 12 (and similarly recited in 
Claims 25, 27, 40, and 42; and 

• "determining whether the user is logged in to a service including the multicast 
channel" and "unsuccessfully authenticating access privileges of the user to 
the multicast channel in response to at least the user not logged in to the 
service including the multicast channel," as recited in Claims 11-12 (and 
similarly recited in Claims 26-27, and 41-42. 

With respect to Claims 10-12, 25-27, and 40-42, the Examiner acknowledges that neither 
Dillon nor Novaes disclose, teach, or suggest the recited features and operations. Rather, the 
Examiner relies upon Ronen, Applicants respectfully submit, however, that Ronen merely 
discloses a method for "establishing a connection on the Internet between applications 
associated with two or more client terminals." (Column 1, lines 7-10). Ronen generally 
discloses that a connection can be established "on the Internet between two client 
applications on client terminals if the client terminal initiating the connection knows the IP 
address of the client terminal at the terminating end of the connection." (Column 1, lines 
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41-45). Such connections may be established for purposes such as Internet Telephony and 
teleconferencing. (Column 2, lines 1-3). Because the method disclosed in Ronen allows an 
"initiating first user at a client terminal ... to establish a cormection over the Internet with a 
destination user's client terminal [by using[ the destination user's e-mail address 
(mary@def.com) to determine the domain name of that user's [Internet Access Service 
Provider (lASP)] (def.com)" (Column 2, lines 3-8), Ronen dispenses with the requirement 
that the initiating user know the IP address of the destination client. 

Specifically, "[w]hen the [destination] user of client terminals 101 logs onto the 
Internet through LASP 102, and provides his or her identity through a logon and identification 
procedure, [destination] client terminal 101 is assigned a temporary IP address that is used for 
the current session." (Column 2, lines 54-58). "Thus, a database 122, associated with lASP 
102, stores a mapping of each client terminal then connected to LASP 102 and its user, and 
the IP address assigned to that terminal." (Column 2, lines 58-61). When a initiating user 
then "wishes to establish a connection over the Intemet with [the] destination user's client 
terminal ... a domain name server (DNS) is queried to obtain the IP address of that lASP." 
(Column 2, lines 3-10). "The client terminal of the initiating user then sends a query to that 
lASP's IP address to obtain the LP address that that LASP has currently assigned to the 
destination user (mary)." (Column 2, lines 10-13). "If that second user is logged on, an 
entry will exist in a database at the destination user's lASP that associates that user (mary) 
with the IP address assigned by the I ASP to that user's client terminal for the current 
session." (Column 2, lines 13-17). Thus, by accessing its associated database, LASP 102 
"can determine whether a particular one its subscribers is currently logged on." (Column 2, 
lines 64-66). "If the destination user is logged on, the application running on the initiating 
user's client terminal then establishes a connection over the Intemet to the destination user's 
client terminal using the determined IP address." (Column 2, lines 21-25). Accordingly, the 
Ronen system is merely used to identify an IP address such that a communication session can 
be established between two client terminals associated with different end users. Because 
Ronen is not at all related to providing multicast communications, Ronen does not disclose, 
teach, or suggest determining whether the user is logged in to a service and/or service 
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provider providing the multicast channel and then unsuccessfully authenticating access 
privileges of the user to the multicast channel in response to at least the user not logged in to 
the service and/or service provider," as recited in Claims 10-12, 25-27, and 40-42. The 
recited features are completely absent from the disclosure of Ronen, 

For at least these reasons, Applicants respectfully request reconsideration and 
allowance of Claims 6-12, 15, 21-27, 30, 36-42, and 45. 



The Examiner rejects Claim 47 under 35 U.S.C. § 103(a) as being unpatentable over 
Gupta in view of Ronen and Novaes, 

First, assuming for the purposes of argument only that the proposed combination of 
Gupta, Ronen, and Novaes discloses the features of Claim 47 (which Applicants dispute 
below), the rejection of Claim 47 is improper at least the Examiner has not sufficiently shown 
that one of ordinary skill in the art at the time of invention would have been motivated to 
make the proposed combination. The mere fact that references can be combined does not 
render the resultant combination obvious unless the prior art also suggests the desirability of 
the combination. In re Mills, 916 F.2d 680 (Fed. Cir. 1990). The showing must be clear and 
particular. See, e.g., C,R. Bard v. M3 Sys„ Inc., 48 U.S.P.Q.2d 1225, 1232 (Fed. Cir. 1998). 
The Examiner has not provided adequate evidence that one of ordinary skill in the art at the 
time of the present invention would have been motivated to modify the load-balancing 
system disclosed in Gupta to include the authentication procedures disclosed in Ronen and 
the Internet group management protocol disclosed in Novaes. The Examiner merely 
speculates "it would have been obvious" to modify the load-balancing system of Gupta to 
include the teachings of Ronen "because by ensuring that the user is logged on and that it is a 
known user, it enhances security so that a third party does not try and intercept services." 
(Office Action, page 8). With respect to Novaes, the Examiner speculates that "it would have 
been obvious" to modify Gupta to include the teachings of Novaes "because multicast 
datagrams are only received if specific group subscriptions exist in a node to keep the 
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overhead of the beacon program to a minimum." (Office Action, page 12). The Examiner's 
speculation, however, does not provide the suggestion or motivation required to make the 
proposed combination and instead simply relies upon hindsight. 

It is improper for an Examiner to use hindsight having read the Applicants' disclosure 
to arrive at an obviousness rejection. In re Fine, 837 F.2d 1071, 1075, 5 U.S.P.Q.2d 1596, 
1600 (Fed. Cir. 1988). In particular, it is improper to use the claimed invention as an 
instruction manual or template to piece together the teachings of the prior art so that the 
claimed invention is rendered obvious. In re Fritch, 972 F.2d 1260, 23 U.S. P. Q. 2d 1780 
(Fed. Cir. 1992). Because the Examiner has merely used Applicants' claims as an instruction 
manual to piece together the load-balancing system disclosed in Gupta with the 
authentication procedures disclosed in Ronen and the Intemet group management protocol 
disclosed in Novaes, Applicants respectfully submit that the proposed Gupta-Ronen-Novaes 
combination is improper and should not be used here to reject Applicants' claim. 

Furthermore, Applicants respectfully submit that one of ordinary skill in the art at the 
time of invention would not have been motivated to make the proposed Gupta-Ronen-Novaes 
combination, Gupta discloses a routing process for reallocating address spaces of a plurality 
of servers using a load balancing policy and a multicast channel. (Title). The objective as 
disclosed in Gupta is to provide a routing process by which network resources may be 
obtained from web servers on networks "hampered by congestion and bottlenecks." (Column 
1, lines 53-56). More specifically, Gupta provides "a simple general purpose interface that 
works across a spectrum of varying user needs . . . [without] unreasonably increas[ing] the 
overhead for setting up and operating the multicast for users who would like to continue to 
set up simple open meetings." (Column 12, lines 5-10). Because open meetings are just that 
- open to all users of the multicast network - one of ordinary skill in the art would not have 
been motivated at the time of invention to combine the load balancing policy of Gupta with 
the authentication procedures disclosed in Ronen and the Intemet group management 
protocol disclosed in Novaes, 
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Second, Applicants respectfully submit the proposed Gupta-Ronen-Novaes 
combination does not disclose, teach, or suggest each and every limitation recited in 
Applicants' Claim 47. For example. Claim 47 recites "receiving an Intemet group 
management protocol request at an access network router, the request identifying a user 
requesting to join an Intemet protocol (IP) multicast channel." The Examiner specifically 
relies upon Novaes for disclosure of the recited features. Applicants have shown above with 
respect to Claim 1, however, that Novaes does not disclose, teach, or suggest the recited 
"Internet group management protocol request." Rather, Novaes merely discloses that a 
"beacon message [is transmitted] over subnetworks 310, 320, and 330 using the multicast 
protocol." (Column 8, lines 39-40, [^/c]). Although the "mechanism used to control the 
distribution of the multicast messages is based in the Intemet Group Management Protocol 
(IGMP) as specified in RFC 1112" (Column 8, lines 40-43), there is no disclosure in Novaes 
that an IGMP request is received that "identif[ies] a user requesting to join an Intemet 
protocol (IP) multicast charmel," as recited in Claim 47. To the contrary, the "beacon 
message" is disclosed as comprising "a short status datagram, which is called heartbeat 
message or beacon status message." (Column 8, lines 26-28). Thus, the beacon message of 
Novaes is merely a status message. Accordingly, for reasons similar to those discussed above 
with regard to Claim 1, there can be no disclosure in the proposed Gupta-Ronen-Novaes 
combination of "receiving an Intemet group management protocol request at an access 
network router, the request identifying a user requesting to join an Intemet protocol (IP) 
multicast channel," as recited in Claim 47. 

As another example of the deficiencies of the proposed Gupta-Ronen-Novaes 
combination. Applicants respectfully submit that the proposed combination does not disclose, 
teach, or suggest "determining whether the user is logged in to a service provider providing a 
service including the IP multicast channel" or "determining whether the user is logged in to 
the service including the IP multicast channel" and "unsuccessfully authenticating access 
privileges of the user to the IP multicast chaimel in response to at least one of determining the 
user is not logged in to the service provider and determining the user is not logged in to the 
service," as recited in Claim 47. With respect to the above recited features and operations. 
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the Examiner specifically relies upon the disclosure of Ronen. Applicants have shown above 
with respect to Claims 10-12, 25-27, and 40-42, however, that Ronen does not disclose, teach, 
or suggest the recited features and operations. To the contrary, Ronen merely discloses a 
method for "establishing a connection on the Internet between applications associated with 
two or more client terminals" and is not at all related to the provisioning of multicast 
communications. (Column 1, lines 7-10). Accordingly, for reasons similar to those 
discussed above with regard to Claims 10-12, 25-27, and 40-42, Applicants respectfully 
submit that the proposed Gupta-Ronen-Novaes combination does not disclose, teach, or 
suggest each and every limitation recited in Claim 47. 

For at least these reasons. Applicants respectfully request reconsideration and 
allowance of Claim 47. 
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CONCLUSION 



Applicants have made an earnest attempt to place this case in condition for allowance. 
For the foregoing reasons, and for other reasons clearly apparent. Applicants respectfully 
request full allowance of all pending claims. 

If the Examiner feels that a telephone conference would advance prosecution of this 
Application in any manner, the Examiner is invited to contact Jenni R. Moen, Attorney for 
Applicants, at the Examiner's convenience at (214) 953-6809. 

Applicants do not believe any fees are due. However, the Commissioner is hereby 
authorized to charge any additional fees or credit any overpayment to Deposit Account No. 
02-0384 of Baker Botts L.L.P. 



Respectfully submitted, 
BAKER BOTTS L.L.P. 



Attorneys for Applicants 




Jenm R. Moen 
Reg. No. 52,038 



Date: April 4, 2005 



Correspondence Address: 



at Customer No. 05073 
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